Related party payment system

ABSTRACT

Systems and methods are disclosed herein which that enable a first party, such as a child, to selected one or more items offered by an online retailer and to send a request to a second party, such as a parent or guardian, to request that the second party purchase the item or items for the first party. The systems and methods provide the second party with the ability to view requests received from the first party, to set limits on the number of requests and the amounts of the requests that the first party may make. The second party may also designate the parties to whom the first party may submit purchase requests. The child may also submit request to one or more non-parental contributors who may contribute money toward the purchase the one or more items for the child.

RELATED APPLICATION

This application is a continuation of Ser. No. 13/894,219, filed May 14,2013, which is a continuation of Ser. No. 13/251,972, filed Oct. 3,2011, now U.S. Pat. No. 8,442,868, which is a continuation of Ser. No.12/609,885, filed Oct. 30, 2009, now U.S. Pat. No. 8,065,190, whichclaims the benefit of U.S. provisional patent application Ser. No.61/109,803, filed on Oct. 30, 2008, all of which are entitled “RELATEDPARTY PAYMENT SYSTEM,” and all of which are incorporated herein byreference in their entirety.

FIELD OF THE INVENTION

The present invention generally relates to the field of paymentprocessing and relates to processing third party funding.

BACKGROUND

Electronic commerce (“e-commerce”), the buying and selling of productsand services over the Internet has flourished with the widespreadavailability of Internet access. Online retailers (also referred toherein as “e-tailers”) may be a traditional brick and mortar retailerswith a physical presence such as a store where customers can shop inperson that also have an online store. Customers may purchase productsor services from both the retailer's brick and mortar stores and theretailer's online store Other online retailers maintain an onlinepresence only and customers purchase goods or services from the onlineretailer's online store.

Customers select products or services that they would like to purchase,and the products and services are “placed” in an electronic shoppingcart or shopping basket. The electronic shopping cart allows users toaccumulate a list of products or services for purchase while browsing anonline shop. A typical electronic shopping card also enables thecustomer to initiate an electronic payment transaction to pay for theselected goods or services. Online purchases are typically fundedthrough various types of electronic financial transactions, such asthrough credit card or debit card transactions.

Many online retailers offer products and services that appeal tochildren, but children do usually do not have a credit or debit cardwith which to purchase these items. Instead, a child typically must aska parent or guardian or a close relative, such as a grandparent, to goonline and purchase a desired item for the child. Conventional onlinepayment systems do not provide a mechanism for a child to request thatparent or other related party pay for desired item for the child.

SUMMARY

Systems and methods are disclosed herein that enable a first party, suchas a child, to select one or more items offered by an online retailerand to send a request to a second party, such as a parent or guardian,to request that the second party purchase the item or items for thefirst party. The systems and methods provide the second party with theability to view requests received from the first party, to set limits onthe number of requests and the amounts of the requests that the firstparty may make. The second party may also designate the parties to whomthe first party may submit purchase requests. The child may also submitrequest to one or more non-parental contributors who may contributemoney toward the purchase of one or more items for the child.

According to an embodiment, a computer-implemented method for processingthird party payment requests is provided where one or more computers areprogrammed to perform specified steps. The steps include receiving athird party payment request from a user to request that a third partypayor fund the purchase of an item from an online retailer for the user,and sending a payment authorization request to a third party payordesignated in the third party payment request. The steps also includereceiving a response to the payment authorization request from the thirdparty payor, and processing the third party payment request to purchasethe item from the online retailer if the response is an authorization topay for the item for the user.

In another embodiment, a computer-readable storage medium having storedthereon one or more sequences of instructions for causing one or moremicroprocessors to perform the steps for processing third party paymentsis provided. The steps include receiving a third party payment requestfrom a user to request that a third party payor fund the purchase of anitem from an online retailer for the user, and sending a paymentauthorization request to a third party payor designated in the thirdparty payment request. The steps also include receiving a response tothe payment authorization request from the third party payor, andprocessing the third party payment request to purchase the item from theonline retailer if the response is an authorization to pay for the itemfor the user.

In yet another embodiment, a system for processing third party paymentsis provided. The system includes a processor connected to a computerreadable storage device for executing programmed modules stored therein.The system also includes a request processing module and a paymentprocessing module. The request processing module is configured toreceive third party payment requests from a user requesting that a thirdparty fund the purchase of an item, send a payment authorization requestto the third party payor, and receive an authorization response from thethird party payor. The payment processing module is configured toprocess the third party payment request to purchase the item from theonline retailer if the authorization response indicates that the thirdparty payor would like to pay for the item for the user.

BRIEF DESCRIPTION OF THE DRAWINGS

The details of the present invention, both as to its structure andoperation, may be gleaned in part by study of the accompanying drawings,in which like reference numerals refer to like parts, and in which:

FIG. 1 is a block diagram of an environment in which a related partypayment system can be implemented according to an embodiment;

FIG. 2 is a block diagram of a related party payment controlleraccording to an embodiment;

FIG. 3 is a flow diagram of a method for requesting the payment for anitem at an online retailer according to an embodiment;

FIG. 4 is a flow diagram of a method for receiving and processingrequests for related party payment requests according to an embodiment;

FIG. 5 is a flow diagram a method for processing payments in response toan approval of a related party payment request according to anembodiment;

FIG. 6 is a flow diagram of a method for a child to manage pendingpayment requests according to an embodiment;

FIG. 7 is a flow diagram of a method for a parent or guardian to managepending payment requests from one or more children according to anembodiment; and

FIG. 8 is a flow diagram of a method for managing a child's accountaccording to an embodiment.

DETAILED DESCRIPTION

Systems and methods are disclosed herein for processing third partypayment requests where a user requests that a third party, such as aparent, pay for all or part of an item or item(s) offered for sale by anonline shop. The user may designate more than one payor in the thirdparty payment request. The designated payors may be a parent or guardianor may be other contributors authorized by the parent or guardian. Oneor more of the designated payors can authorize a payment of all or partof the requested amount or the payors may decline the payment. If apayor or combination of payors provides the full amount requested in thethird party payment request, payments are drawn from funding sourcesassociated with each of the payors that authorized the payment. The useraccount is also associated with a supervisory account (also referred toherein as a parent account) that is associated with a person who has theauthority to set limits on the number of requests that a user can make,the amount that a user may request, and/or set other limits on theuser's ability to request third party payments to pay for items from anonline retailer.

After reading this description, it will become apparent to one skilledin the art how to implement the invention in various alternativeembodiments and alternative applications. Although various embodimentsof the present invention are described herein, it is understood thatthese embodiments are presented by way of example only, and notlimitation. As such, this detailed description of various alternativeembodiments should not be construed to limit the scope or breadth of thepresent invention.

Throughout this description the term “child” is used to designate personfor whom a payment in made to a payee in exchange for a product orservice offered for sale by the payee. The terms “parent” and “guardian”are used to refer to a supervisory payor in the related party paymentsystem that can make payments to payees on behalf of a “child” entity,can monitor the transaction histories of “child” entities, can authorizeor decline these transactions, and impose limits on request for thirdparty payments that can be made by the a child. However, the systems andmethods described herein are not merely limited to a parent-childrelationship and may be applied to other types of relationships where asupervisory entity monitors and/or makes third party payments on behalfof another entity.

In one embodiment, the systems and methods described herein can beimplemented in the environment illustrated in FIG. 1. The environmentincludes user devices 12 and 18, an electric retailer server 14, and arelated party payment server 16, and network 20. Electronic retailerserver 14 is a network-connected server computer system that is used toimplement an online shop for an online retailer from which users canpurchase products and/or services from an electronic catalog of productsand/or services. In some embodiments, electronic retailer server 14 maybe a collection of servers used to implement an online shop, such as webserver for implementing a web page interface for the online shop and adatabase server for storing product and/or service information andtransactional information.

The electronic retailer server 14 can provide an online shop thatincludes a shopping cart or other payment-related interface that allowsa child to select one or more items for purchase from the online shopand to indicate that the child would like to pay for the selected itemor items using a third party payment where someone else pays for theitem or items for the child. The online retailer server 14 can then senda third party payment request to the related party payment server 16 forprocessing. The online shop can suspend the child's shopping cart whilethe third party payment request is processed and complete thetransaction if the third party payment request is authorized by a payor.According to an alternative embodiment, the electronic retailer mayintegrate a button or other navigational element, such as a link,directly on a product web page within the online shop. Instead of addingthe item to the online shop's shopping cart, the child can click thebutton or activate navigational element to generate a third partypayment request. The button may redirect the child to a payment requestinformation screen where the child can select the payors (e.g. a parentand/or one or more contributors) who will receive the third partypayment request.

Related party payment server 16 is a network-connected server computersystem or set of computer systems that can be used to implement thevarious related party payment processing techniques described herein.The related party payment server 16 is configured to process paymentrequests from a child, to present payment request to a parent or otherpayor (referred to herein as “contributors”), and to execute paymentprocessing on approved payment authorization requests. Related partypayment server 16 may communicate with payment processing networks,banks, and/or other financial entities (not shown) for processingpayment transactions.

The related party payment server 16 provides for three types ofaccounts: child, parent, and contributor. Child accounts can be used tomake third party payment requests to a parent and/or one or morecontributors. A child account also enables a child to view pending thirdparty payment requests and modify or cancel the pending requests. Aparent account is a supervisory account that is able to manage one ormore child accounts, approve or decline payment requests submitted tothe parent by the child, and set various limits on what each child cando. For example, the parent account can limit the number of third partypayment requests that a child can create over a specified period oftime, and can also set monetary limits on those requests as well. Theparent account may also have one or more funding source associated withthe parent account for paying authorized payment requests. Parentaccounts can also view the transaction histories associated with each ofthe child account associated with the parent account. The parent accountalso enables the parent to impose limitations on which contributors maydesignate as payors. Contributor accounts enable third parties, such asgrandparents, to receive third party payment requests from a child, viewpending requests sent to the contributor account, authorize or declinethe pending requests, and to set up funding sources from whichauthorized third party payment payments can be withdrawn. The parentand/or contributor accounts may also be used to view messages send tothe parent or contributor by the child. Related party payment server 16provides a user interface, such as a web page or set of web pages, forchildren, parents, and contributors to log into their accounts andperforming the various functions outlined above.

Related party payment server 16 is also configured to communicate withelectronic retailer server 14 to receive product information, paymentrequest information from the electronic retailer server 14 and toprovide payment transaction information to the electronic retailer,including payment processing details for approved payments, andnotifications whether a pending transactions has been approved or deniedby a payor. In an embodiment, the related party payment server 16 isimplemented by the electronic retailer and can be implemented on theelectronic retailer server 14. In other embodiments, the related partypayment server 16 is implemented as a separate server or set of serversfrom the electronic retailer server 14.

User devices 12 and 18 are computing devices. Each user device comprisesa processor, a network interface card, and memory. User devices 12 and18 may be implemented as various types of computer systems, such aslaptop computers, handheld computers, mobile phones, and/or otherdevices that have processors and browser software capable of accessingand displaying web pages from the Internet. The network interface cardof the user device provides a wired or wireless connection to network20. Network 20 is a public network or set of interconnected networks,such as the Internet. User devices 12 and 18 can communicate with theelectronic retailer server 14 and the related party payment server 18via network 20. In an embodiment, user devices 12 and/or 18 may beconnected to network 20 via one or more intermediate networks, such as alocal area network (LAN), wide area network (WAN), personal area network(PAN), or wireless network. User devices 12 and 18 include browsersoftware that enables to the user to access the respective web pages ofthe related party payment server 16 and the electronic retailer server14.

FIG. 2 is a high level block diagram of a related party paymentcontroller 200 that can be implemented on related party payment server16 according to an embodiment. Related party payment controller 200includes a user interface module 210, an account manager module 220, arequest processing module 230, a payment processing module 240, and amessaging module 250. The related payment party controller 200 iscommunicatively coupled to one or more persistent data stores forstoring and accessing information used by the related party paymentcontroller 200 in processing payment requests and payments. In anembodiment, the data stores may be implemented using a relationaldatabase. In the embodiment illustrated in FIG. 2, related party paymentcontroller 200 is communicatively coupled to an account information datastore 250, a message data store 255, a payment processing data store260, a payment requests data store 265, and a merchant information datastore 270.

User interface module 210 provides user interfaces, such as a web pageor set of web pages, for users to interact with the related partypayment system. For example, the user interface module 210 provides aninterface for a child to create a payee account that identifies a parentor guardian responsible for supervising the child's payment requests andfor approving or denying at least a portion of the payment requests.

The user interface module 210 also provides a third party paymentrequest (e.g. a “Bill My Parents”) interface that can be integrated intothe shopping cart or payment interfaces of an online shop provided by anelectronic retailer. For example, an electronic shop provided byelectronic retailer server 14 may include a button or link on a paymentinterface provided by the shop that allows a user to initiate thirdparty payment processing for a purchase from the online shop. In anexample, a child wishing to purchase a video game from an online videogame retailer adds the video game to the electronic shopping cart on theonline video game retailer's web site, and selects a “Bill a ThirdParty” as the payment option for the website. The “Bill a Third Party”option then sends a request to the related party payment server 16 toprocess the request. The user interface module 210 of the related partypayment controller 200 of the related party payment server 16 can thenrespond to the request by providing a user interface for the child tologin to an existing payment account or to create a new account on therelated party payment system provide by related party payment server 16.Once the child has created a new account or logged into a new account,the child can then send a payment request to one or more payors who maypurchase the item for the child.

Account manager module 220 is configured to access account informationdata store 250 to retrieve information about child, parent, orcontributor accounts and to store account information in the accountinformation data store 250. The account manager module 220 is configuredto interface with user interface module 220 to provide accountinformation to be displayed on the various user interfaces provided bythe related party payment system and to store account relatedinformation entered by users of the system. The account manager moduleis also configured to handle authentication of usernames and passwordsof children, parents, and/or contributors who attempt to log into theiraccounts. If a user provides a valid username and password combination,the account manager module 220 instructs the user interface module 210to display an account maintenance screen that is appropriate for eachtype of user. For example, the account maintenance screen associatedwith a child may only allow the user to view information related to thatclient, such as pending requests submitted by the client, requests thathave already been processed, and messages sent to the child by theparent or guardian or by a contributor, such as a grandparent. If userprovides an invalid username and password combination, the user isdenied access to the account maintenance screens

The account information stored in the account information data store 250can include different information for the user depending upon the typeof account that is associated with the user. For example, a child'saccount can include information such as a contact email address, thechild's name and age, a designated parent and guardian for the child andcontact information for that parent or guardian, and contactinformation, such as email addresses or telephone numbers, for otherpayors associated with the child. A parent account or a contributoraccount can have payment source information associated with the account.For example, the parent may associate one or more credit or debit cardswith the account or may provide a checking account from which paymentsmay be debited.

Request processing module 230 is configured to access payment requestsdata store 265 to access third party payment request information storedtherein and to update or delete existing third party payment requestinformation or to add new third party payment request information. Therequest processing module 230 is configured to interface with userinterface module 220 to provide payment request related data forpopulating payment request data in the user interfaces generated by userinterface module 220 and for storing in payments request data store 265payment request data entered into the user interface by the users. Thepayment request data stored in payment requests data store 265 includesvarious information related to the payment request, such as the price ofthe item requested, the name of the item requested, a transactionidentifier for the transaction that has been suspended pending theprocessing of the payment request, and the payor or payors designated inthe payment request.

Request processing module 230 also accesses, updates, and deletesinformation from merchant information data store 270. Merchantinformation data store 270 is used to store merchant specificinformation related to a payment request, such a Universal ResourceLocator (“URL”) linking a description and/or image of an item that thechild would like the payor or payors to purchase for the child. Themerchant specific information may also include a link to generalinformation about the ecommerce retailer, such as the return policies,shipping costs, and/or other information related to the merchant. In anembodiment, the merchant related information may be displayed in theuser interface displayed to a payor when a payor selects a paymentrequest to review. In an example, a child submits a payment request fora video game from a video game merchant.

Payment processing module 240 is configured to process payments forpayment requests that have been approved by a payor. Payment processingmodule 240 accesses payment information from the payment processing datastore 260 and adds payment information to the payment processing datastore 260. The payment processing data store 260 may includeinformation, such as a payment request identifier for associating thepayment back to a particular payment request, a payor name, and apayment source identifier, such as a credit or debit card number, achecking account number for electronic check processing or direct debit,and/or other payment source identifiers. The payment processing data mayinclude the other payment related information such as the date that thepayment request was submitted to the payment processing network, thestatus of the payment (e.g., pending or processed), and/or other paymentrelated information.

In one embodiment, the payment processing module 240 is configured toprocess payment transactions using third party payment processors, suchas payment processing networks for credit card, debit card, check cardtransactions, or electronic checks. The payment processing module 240provides the payment related information to the payment processingnetwork and the payment processing network processes the transaction. Insome embodiments, the payments are processed and credited to an escrowaccount associated with the related party payment service. Once themoney has been credited to the escrow account, the funds may be paid tothe electronic retailer through various methods, such as electronicallydepositing the funds into a specific account provided by the electronicretailer, and the retailer notified that the payment for the pendingtransaction has been completed so that the retailer can complete thepending transaction (e.g., pack and ship the goods to the child who madethe third party request). In some embodiments, the funds for a retailermay be transferred as soon as the funds are available in the escrowaccount. According to other embodiments, the funds for a particularretailer may be periodically credited to the retailer

In some embodiments, the payment processing module 240 may not processthe payment directly, but instead may provide the payment sourceinformation, such as the credit card number, debit card number, or otherinformation to the electronic retailer for processing. The electronicretailer may then process the payment using whatever methods theretailer typically uses for payment processing. The merchant informationdata store 270 may include the information payment account informationfor the retailer that identifies an account where the money held inescrow by the related party payment system may be transferred.

Messaging module 250 is configured to allow users to send and receivemessages regarding payment requests to one another. For example, a childmay send a message to a parent or a guardian explaining why they wantthe parent or guardian to pay for a particular item. The parent may inturn send a message to the child asking for more information or statingwhy the parent will accept or deny the payment request. Message module250 is configured to access message data from and to write message datato message data store 255.

FIG. 3 is a flow diagram of a method for requesting the payment for anitem at an online retailer according to an embodiment. A child accessesan online store of an electronic retailer (step 300) and selects one ormore items that the child would like to have a parent or other payorpurchase or the child (step 305). In one embodiment, at the payment orcheckout screens of electronic shop, the child selects a “bill to thirdparty” option on the website (step 310). For example, a website for anelectronic retailer may include a number of payment options, such as apayment by credit or debit card, payment by electronic check, or “billto third party” such as a parent or guardian. If the credit or debitcard option or the electronic check options are selected, the electronicretailer can collect the appropriate account information from the childand submits the account information to a payment processing network,bank, or other processor in order to process the payment for thetransaction. However, as described above, a child typically will nothave access to a credit or debit card or a bank account, and a parent orguardian may not wish to share this account information to prevent thechild from making other unauthorized purchases from other electronicretailers without the express permission of the parent. Therefore, webretailers may offer the additional option of billing a third party forthe items that the child would like to purchase. In an alternativeembodiment, the electronic retailer may integrate a button or othernavigational element, such as a link, directly on a product web pagewithin the online shop. Instead of adding the item to the online shop'sshopping cart, the child can click the button or activate navigationalelement to generate a third party payment request without having to addthe items to the online shop's shopping cart. In an embodiment, theelectronic retailer's product information is captured and is used tocreate a virtual shopping cart. The virtual shopping card can operatesimilarly to an electronic shopping card that is integrated into theretailer's online shop, allowing the child to add additional products orservices to the virtual shopping card and to purchase the items in thevirtual shopping card. The related party payment system is used forfunding the purchase of the items in the virtual shopping card throughthird party payment requests. The related party payment system can alsogenerate reports for the online retailer to identify purchases that arebeing funded via third party payments that identify the items that wereselected and the status of the funding for these items.

If the child has selected the “bill to third party option,” the serverpresents the child with a login screen generated by user interfacemodule 210. The login screen provides inputs for entering the usernameand password that the child selected when the child created an accountwith the system previously. In one embodiment, the username of the childmay be the child's email address. In an embodiment, the login screenincludes a link or a button that enables the child to have his or herpassword emailed to him or her if the child has forgotten theirpassword. In other embodiments, clicking the “forgot password” link orbutton causes the related party payment server 16 to email the child'slost password to the parent and the parent can provide the passwordinformation to the child.

If the child already has an account with the system, the child canprovide his or her login information at the login screen in order to loginto the system (step 330). A child must have a login established withthe system that includes a designated parent or guardian that isresponsible for monitoring the child's payment requests prior to thechild being able to use the third party billing option on electronicretailers' websites.

If the child does not already have an account, the child can select a“new account” link or button on the login screen. The child is thenpresented a series of account creation screens generated by userinterface module 210 of the related party payment controller 200 (step320). The account creation screen gathers basic information from thechild, such as the child's name, email address, and a password that thechild would like to use to log on to the related party payment systemagain in the future. The child must then designate contact informationfor a parent or guardian for the child (step 325). The parent orguardian is responsible for the child and can view and approve or denypayment requests submitted by the child. The parent or guardian may alsobe designated either in whole or in part as a payor on the transactionssubmitted by the child. According to one embodiment, the parent orguardian must approve the creation of the account before the child canbegin creating third party payment requests. Upon setting up theaccount, the parent or guardian is notified that the child has attemptedto create a third party payment account and that the parent must visitthe website for the related party payment system in order to completethe setup of the account. The parent can then authorize the creation ofthe child's account and/or create an account for the parent. The parentmay be notified via email, a text message on a mobile phone, or viaother means depending upon the parent or guardian contact informationprovided by the child.

Once the child has been logged into the system, a “create third partypayment request” interface is generated by the user interface module 210and displayed to the user. The create third party payment requestinterface allows the child to select a third party payor or payors towhom a payment request for the item or items will be sent (step 340).The third party payor or payors will be billed for the item or itemsselected by the user if the third party payor or payors approve thethird party payment request. In an example, a child may send a paymentrequest to multiple payors, such as to a parent and a grandparent, in anattempt to get either the parent or the grandparent to pay for theselected item or items. In one embodiment, each of the designated payorsmay contribute a portion of the total purchase price for the item oritems included in the payment request. If the contributions from each ofthe payors are sufficient to cover the total amount due for the pendingtransaction, the purchase will be completed and the individual payorsbilled for the amount authorized by that payor.

The create third party payment request interface can also provide aninput field where the child can enter an optional message to be sent tothe designated payors (step 345). For example, the child could include amessage “Hi Grandma! This is the game I told you about earlier that Iwould like to have for my birthday. Could you get it for me???Please!!!”

At step 350, the child submits the request for third party payment tothe related party payment system. The related party payment system sendspayment authorization requests to each of the payors designated by thechild in the payment request and can also notify the parent or guardianthat the child has submitted a request for payment. The electronicretailer is also notified that the payment requests have been submittedto the third party payors. The electronic retailer may then suspend thetransaction until the notification has been received from the relatedparty payment server 16 that the payment has been received and thetransaction can be completed or that the payment requests have beendenied and transaction should be canceled.

In an embodiment, a child may reassign a pending third party paymentrequest to a different payor at any time. For example, if the child hassent a request to a parent request that the parent fund the purchase ofa particular item for the child, the child may log in to the relatedparty payment system, select the pending payment request from the listof pending payment requests associated with the child, and reassign thepending payment request to another contributor. For example, the childmay reassign a pending payment request from a parent to a grandparent.In one embodiment, a child may also add an additional payor, such as aparent or other contributor, to a pending payment request or remove adesignated payor from the pending payment request.

FIG. 4 is a flow diagram of a method for receiving and processingrequests for related party payment requests according to an embodiment.The method illustrated in FIG. 4 can be used to implement the variousfunctionality of the related party payment server illustrated in FIGS. 1and 2. The related party payment server 16 receives a third partypayment request submitted by a child (step 400). The child submittingsuch as request is described in step 350 of the method illustrated inFIG. 3. The third party payment request may be received from anelectronic retailer server 14 hosting an online shop that allows thirdparty payments. The electronic retailer's online shop sends a request tofor a third party payment to the related party payment server 16. Thefunctionality to send the request for the third party payment may beintegrated into a shopping cart feature of the online shop or may beaccessed via a standalone a navigational element that allows the childto select an item by clicking on or otherwise activating thenavigational element.

The third party payment request includes various information thatidentifies the item or item(s) to be purchased from the online shop aswell as the payors who the child has designated to receive the thirdparty payment request. For example, the third party payment request mayinclude a item name, item description, a URL or other type of directlink to each of the requested items in the online shop, a uniqueidentifier for each item used by the retailer to identify the item, suchas a Universal Product Code (“UPC”) typically encoded on a barcode foundon many products sold throughout North America, an InternationalStandard Book Number (“ISBN”) used to identify books, or anotherstandard's based or merchant assigned item number.

Upon receiving the third party payment request, a login screen isdisplayed to the child (step 402) requesting that the child login orcreate a new user account. The user interface module 210 may provide aweb page login interface that includes inputs for entering a usernameand password, and a button or other navigational element that, whenactivated, causes the related party payment controller 200 to display anaccount creation interface to the child. If the child does not have anaccount (step 405) and elects to create a new account, a new accountcreation screen or set of screens is displayed to the user (step 410).In an embodiment, the user interface module 210 provides a “create newaccount” form as a web page for display in the browser softwareinstalled child's user device 12 or 18. The child enters various accountinformation into the form, such as the child's name, email address, andthe name and contact information for a parent or guardian. This accountrelated information is received by the related party payment server 16when the child submits the form (step 412), and a new user account iscreated for the child (step 414). In an embodiment, the user interfacemodule 210 receives the account information data submitted by the userand passes the data to the account manager module 220, which creates anew account for the user and stores the account information in theaccount information data store 250.

If the child has a user account, the child enters his or her usernameand password into the login interface and submits the login informationto the server in order to gain access to the system. The server receivesthe login information submitted by the child (step 420), and retrievesthe account information for the child. In an embodiment, the userinterface module 210 receives the username and password data submittedby the user and passes the data to the account manager module forverification. If the child has an existing account, the accountinformation for the child's account is retrieved from the accountinformation data store 250 by the account manager module 250.

Once the child has logged in and/or created a user account, a “createthird party payment request” data entry screen is displayed to the child(step 424). In an embodiment, the third party payment request entryscreen is a web page that is provided by the user interface module 210for display in the browser software installed on the child's user device12. The third party payment request screen includes inputs that allowthe user to designate one or more third party payors related to thechild that may pay for the item or items. For example, the child maysend a payment request to both a parent and grandparent for the sameitem, and either the parent or the grandparent may pay for the item oreach may contribute a portion of the cost of the item. The user submitsthe “create third party payment request” form and the related partypayment server 16 receives the third party payment request data (step425). The user may also optionally include a message to be displayed tothe payors. The data received by the related party payment server 16 isstored in the payment processing data store 260 by the requestprocessing module 230.

A determination is made whether the minimum required data needed toprocess a third party payment request has been received (step 426). Inan embodiment, a child needs to designate only a payor and the requestprocessing module 230 generates a payment authorization request for theitem and sends the payment authorization request to the payor via email,text message, or other methods included in the payor contact informationstored in the account information data store 250. If the child has notdesignated a payor or has not provided other required information the“create third party payment request” screen is displayed again with theinformation entered by the user pre-populated in the form and with anyrequired fields for which data was not provided highlighted.

A payment authorization request is sent to the child's designated parentor guardian (step 430). In the embodiment illustrated in FIG. 4, theapproval request is merely sent to a single payor, the parent. However,the method steps described herein similarly apply to embodiments where anon-parent or non-guardian contributor is designated as a payor or wheremultiple payors are designated in a third party payment request. In anembodiment, when multiple payors are designated in a third party paymentrequest, a separate payment authorization request is generated for andsent to each of the designated payors.

The payment authorization request may comprise an email or other type ofmessage indicating that the child has requested that the parent buy aparticular item (step 430). In one embodiment, the payment authorizationrequest includes a link the item at the online shop, the total amountrequested, a description of the item, and any optional message that mayhave been included in the third party payment request data submitted bythe child. In one embodiment, a parent may receive a notification, suchas an email or a text message that a new payment authorization requesthas been received and that the parent should log in to view the request.In this embodiment, the parent accesses a URL that links to a userinterface that allows the parent to view pending payment authorizationrequests and to authorize or deny these requests (step 432). In anembodiment, the URL may be embedded in the payment authorization requestmessage that was sent to the parent and the parent may click on orotherwise activate this link to view the request.

Once the parent's request to view the payment authorization request hasbeen received, a login screen is displayed to the parent to allow theparent to enter his or her username and password and to submit the logincredentials to the related party payment server 16. Alternatively, theparent can opt to process the payment authorization request withoutlogging into the system (step 436). The login screen may include a linkor other navigational element that allows a parent to proceed withoutlogging in to the system.

If the parent has a user account and wishes to login, the parent entershis or her username and password into the login interface and submitsthe login information to the server in order to gain access to thesystem. The server receives the login information submitted by theparent (step 439), and retrieves the account information for the parent(step 440). In an embodiment, the user interface module 210 receives theusername and password data submitted by the parent and passes the datato the account manager module for verification. If the parent has anexisting account, the account information for the parent's account isretrieved from the account information data store 250 by the accountmanager module 250.

If the parent does not have an account and elects to create a newaccount, a new account creation screen or set of screens is displayed tothe parent (step 442). In an embodiment, the user interface module 210provides a “create new account” form as a web page for display in thebrowser software installed parent's user device 12 or 18. The parententers account information into the form, such as the parent's name andcontact information. The parent may also provide payment sourceinformation such as a credit card or a debit card number or a bankaccount number. This account related information is received by therelated party payment server 16 when the parent submits the form (step444), and a new user account is created for the parent (step 446). In anembodiment, the user interface module 210 receives the accountinformation data submitted by the parent and passes the data to theaccount manager module 220, which creates a new account for the parentand stores the account information in the account information data store250.

After the parent has logged in, created an account, or opted out ofcreating or an account or logging in, a payment authorization requestscreen is displayed to the parent (step 448). In an embodiment, thepayment authorization request screen is a web page displaying detailsabout the pending payment request is displayed, such as the item thatthe child would like the payor or payors to purchase, the merchant fromwhich the item was ordered, the cost of the item, the date that thepayment request was submitted to the payors, and the payors to whom therequest was submitted. The payment request information may also includethe whether any of the payors have approved a payment request for aportion of the amount due for the item, and what the remainingunapproved amount that is still needed in order to purchase the itemfrom the electronic retailer. The parent has the option to approve thepayment authorization request, decline the request, or to take noimmediate action on the request, which leaves the request pending.

If the parent declines the payment authorization request, the requestprocessing module 230 updates the status of the request in the paymentrequest data store 265 to indicate that the third party payment requesthas been declined (step 452). A message is also sent to the child and tothe merchant indicating that the payment request has been denied (step454). In embodiments where the “Bill to Third Party” functionality isintegrated into the shopping cart of an online shop, the merchant maythen cancel a suspended transaction since the payment authorization wasdeclined. In embodiments where multiple payors have been designated on athird party payment request, if one payor declines, the other payors andthe child are notified that the payor declined and the remaining payorsmay still individually decline or authorize the transaction. The thirdparty payment request remains pending until all of the payors decline orauthorize the transaction, and the merchant is not notified until all ofdesignated payors have declined or authorized the transaction. In anembodiment, if one payor authorizes a payment of the full outstandingamount on a pending transaction, the system may mark the other payorswho have not yet responded as “declined” so that the transaction may beprocessed and no outstanding payment authorization requests remainpending.

If the parent authorizes the payment authorization request, the requestprocessing module 230 updates the status of the request in the paymentrequest data store 265 to indicate that the third party payment requesthas been authorized (step 460). A message is also sent to the child andto the merchant indicating that the payment request has been authorized(step 460), and payment processing is performed to bill the parent forthe authorized amount. FIG. 5 illustrates one method of paymentprocessing the may be used according an embodiment.

According to an embodiment, the parent may also chose a shipping addressfor the items being funded so that the items are shipped to the parentrather than directly to the child. This allows the parent to moreclosely monitor the items that the child is ordering. For example, aparent may wish to have a DVD or book that the child has requested sentto the parent so that the parent can determine whether the content isappropriate for the child before the item is given to the child.

In the event that a parent has not logged into the system or has notprovided payment source information, the related party payment server 16displays a screen requesting that the payor provide payment sourceinformation, such as a bank account number, credit card number, or debitcard number. The payment source information entered by the parent canthen be used to process the payments (step 464).

In some embodiments, when a child designates multiple payors and onepayor authorizes payment authorization request for less than the fullamount required to pay the items in full, the payment request data store265 is updated to indicate that the payment amount third party paymentrequest has been paid in part. The child is notified that part of therequested payment amount has been paid by one of the payors designatedassociated with the third party payment request. In one embodiment, theother designated payors associated with the third party payment requestmay also be send a message notifying that one of the designated payorshas made a partial payment.

In an embodiment, the online retailer is provided a report that providesspecific details of all third party payment requests that have been madefrom the retailer's online shop and whether any payments were made tofund the purchase of these items. The reports identify each item thatwas requested, the date that the item was requested, the status of therequest (e.g., pending, paid, etc.) and the amount paid if a third partypayment has been made to fund the purchase of the requested item. In anembodiment, a report may be generated and transmitted to the payorperiodically by the related party payment processing system. In someembodiment, the merchant may be provided with a user interface, such asa web page, via user interface module 210 that enables the onlineretailer to log into the system and view third party request data andpayments data related to the retailer's online shop.

FIG. 5 is a flow diagram a method for processing payments in response toan approval of a related party payment request according to anembodiment. The method illustrated in FIG. 5 may be used to implementthe process payments step 464 of the method for processing third partypayment requests illustrated in FIG. 4. In one embodiment, the relatedparty payment processing system may check for other pending payments toan electronic merchant from the same payor (step 500). For example, achild may have sent payment requests for two or more payment requestsfor items on the same electronic retailer's online shop to the samepayor. Rather than process the payments separately for thesetransactions, it may be more cost effective to process a singleelectronic payment for the total amount of all of the transactions. Ifmultiple pending and approved transactions exist for the payor and theelectronic retailer (step 505), the total amount payment amount due forall of the identified transactions is determined (step 510).

A determination is made whether the payor has designated a credit cardas the funding source for the payment (step 512). If a credit card hasbeen designated as the funding source, the credit card can bepreauthorized (step 515) for the amount of the payment to determinewhether the charge to the card would be declined or authorized by thepayment processing network or the bank that issued the credit card.Preauthorization of the credit card can save the electronic retailerfrom incurring payment processing charges for the credit card if thecharge is declined. A determination is made whether the preauthorizationof the credit card was successful (step 520). If the preauthorization isdeclined, the payor and the merchant can be notified that thepreauthorization has failed (step 525), and the pending request forpayment may be updated to indicate that the credit card transaction wasdeclined (step 530). A notification message may also be send to thechild and the payor indicating that the transaction has failed (step535). In some embodiments, the merchant may not be notified at step 525that the preauthorization failed, and the payor may be sent a message bythe system at step 535 providing the payor with the opportunity toselect an alternative funding source for the transaction and to processthe payment using the alternative funding source. In some embodiments,the child may be sent a message at step 525 that enables the child toselect an alternative payor and to generate a payment request to thealternative payor.

The payment is processed (step 540) via payment processing network,bank, or other electronic payment system, depending upon the source offunding that was selected by the payor. A determination is made whetherthe payment process successfully (step 542). The payment processingnetwork may decline a transaction due to insufficient funds or forvarious other reasons. If the payment is declined, the payor and themerchant can be notified that the payment has been declined (step 565),and the pending request for payment may be updated to indicate that thepayment transaction was declined and that the request is pending (step570). A notification message is then send to the child and the payorindicating that the payment transaction has failed (step 535). Themerchant may optionally cancel the pending transaction at due to thedeclined payment transaction. In some embodiments, the merchant may notbe notified at step 565 that the payment was declined, and the payor maybe provided the opportunity to select an alternative funding source andto process the payment using the alternative funding source. In someembodiments, the child may be sent a message at step 565 that enablesthe child to select an alternative payor and to generate a paymentrequest to the alternative payor.

In an embodiment, if the payment processes successfully the funds fromthe payment are credited to an escrow account maintained by the relatedparty payment system (step 545). The related party payment system thentransfers the funds from the escrow account to electronic retailer'saccount (step 550). The transfer may occur as soon as funds areavailable in the escrow account. In an embodiment, the funds may be heldin the electronic escrow account until a threshold balance is reached inorder reduce transactional costs incurred by transferring money from theescrow account to the electronic retailer's account. In anotherembodiment, scheduled transfers may be made from the escrow account tothe electronic retailer's account (e.g., weekly or monthly transfers). Amessage indicating that the transaction has completed can then begenerated and sent to the payor and the child and the status of thepending transaction request may be changed to a “paid” status in therelated party payment system (step 555).

FIG. 6 is a flow diagram of a method for a child to manage pendingpayment requests according to an embodiment. A child may view, modify,or delete pending payment requests. The child must first login to theserver by entering a URL of a login page into a web browser located on auser computer 12 or 18 (step 600). The user interface module 210 of therelated party payment controller 200 generates a login screen userinterface web page to be displayed to the child. After logging into thesystem, the child is presented with a web page or series of web pagesthat enable the child maintain the child's account and view and/ormodify pending requests. The web pages can include both pending andprocessed payment requests.

The child can select a pending payment authorization request (step 605)to view and/or modify from a listing of pending payment authorizationrequests. A web page displaying details about the pending paymentrequest is displayed, such as the item that was ordered, the merchantfrom which the item was ordered, the cost of the item, the date that thepayment request was submitted to the payors, and the payors to whom therequest was submitted. The payment request information may also includethe whether any of the payors have approved a payment request for aportion of the amount due for the item, and what the remainingunapproved amount that is still needed in order to purchase the itemfrom the electronic retailer.

The child may decide to send a reminder to a payor who has not yetresponded to a payment authorization message sent to the user inresponse to a third party payment request initiated by the child (step610). A reminder message is generated and sent to the designed payorreminding the payor that the payment authorization for the payment (step612). The message may be sent using email, a text message to a mobilephone, or via other means specified in the payor contact information forthat payor. In an embodiment, the child may also select the type ofreminder message to be sent (e.g., text message or email) and may alsoprovide a short message to be included with the reminder.

A child may also decide to add a new payor to a pending third partypayment request (step 620). For example, the child may have originallydesignated a grandparent as the payor for a payment request, but maylater decide to add a parent as a payor on the payment request. Thepending payment request information user interface can provide a buttonor other control, such as a hyperlink, that the child can activate toindicate that the child would like to add an additional payor to apending third party payment request. The user interface module 210causes an “Add Payor” user interface web page to be displayed to theuser in response to the request to add an additional payor to thepending request. The child selects a new payor to associate with therequest, enters an optional message to the new payor, and submits therequest to add the new payor. In response to the request, the systemgenerates a payment authorization message to the new payor (step 625).In an embodiment, the parent or guardian of the child is also sent amessage indicating that the child has added a new payor to a pendingpayment request (step 630). In an embodiment, the parent may optionallyblock the addition of the new payor to the pending payment request.

The child may also decide to view messages associated with the pendingrequest (step 635). In an embodiment, the child may click on a “readmessage” button or hyperlink that causes the user interface module 210to generate a message interface that enables the user to read andrespond to messages. A payor or the parent or guardian may send messagesto the child about a pending request. For example, a parent might send aquestion to the child, “I thought we just bought you a new set of shoesfor basketball last month when school started. What happened to thoseshoes?” The child may then optionally send a message in response tothese messages (step 640). For example, the child might respond, “But Ineed a new set of cleats for football as well!”

The child may also decide to cancel a pending request for third partypayment (step 645). If the child decides to cancel a pending request fora third party payment, the pending request information stored in thepayments request data store 265 is updated to indicate that the paymentrequest has been canceled (step 650). The payor(s) and the merchantassociated with the pending request are also notified that the child hascanceled the pending request (step 655). In response, the merchant cancancel the transaction that was suspended at the merchant's online shoppending the authorization of the payment request or payment requestsassociated with the transaction.

FIG. 7 is a flow diagram of a method for a payor to manage pendingpayment requests from one or more children according to an embodiment.The payor may be a parent or guardian of the child making the request orthe payor may be another related third party payor designated on a thirdparty payment request issued by the child.

The payor can first log into the server by entering a URL of a loginpage into a web browser installed on the payor's computer system (e.g.,user device 12 or 18) (step 700). The user interface module 210 of therelated party payment controller 200 generates a login screen userinterface web page to be displayed to the payor. After logging into thesystem, the payor is presented with a web page or series of web pagesthat enable the payor to view and/or authorize pending requests. The webpages can include both pending and processed payment requests on whichthe payor was designated.

A payor may have pending payment authorization requests associated withmultiple children. For example, a grandparent with multiplegrandchildren may have pending payment authorization requests associatedwith more than one of their grandchildren. The payor may select a childfor which the payor would like to view pending requests (step 705), anda list of pending payment authorization request associated with theselected child is displayed to the payor.

The payor may then select a particular pending payment authorizationrequest for processing (step 710) to view and/or authorize. A web pagedisplaying details about the pending payment request is displayed, suchas the item that was ordered, the merchant from which the item wasordered, the cost of the item, the date that the payment request wassubmitted to the payors, and the payors to whom the request wassubmitted. The payment request information may also include whether anyof the payors has approved a payment request for a portion of the amountdue for the item, and what the remaining unapproved amount that is stillneeded in order to purchase the item from the electronic retailer.

The payor may then choose to view the item at the merchant's website(step 715). The user interface that displays the pending payment requestmay include a link or other navigational element to each of therequested items on the online merchant's website. Activating the link orthe other navigational element can direct the browser installed on theuser's computer system to access the page of the online shop for an itemthat the child would like the payor to purchase for the child.

The payor may also choose to send a message to child about the pendingpayment authorization request (step 730). In an embodiment, the messageis viewable by the child by logging into the related party paymentsystem. In some embodiments, the message may also be sent to the childvia email or text message. In an example, a payor may send a messagerequesting more about the product or why the child would like the payorto purchase the product.

The payor may also decide whether to authorize or decline the paymentrequest (step 735). If the payor decides to decline the paymentauthorization request, a decline payment message is sent to the serverand the server processes the declined payment request according to steps452 and 454 of the method illustrated in FIG. 1. If the payor authorizesthe payment, then an authorize payment message is sent to the relatedparty payment server 16 and the server processes the authorizationaccording to steps 460, 462, and 464 of the method illustrated in FIG.1.

FIG. 8 is a flow diagram of a method for managing a child's accountaccording to an embodiment. A parent or guardian may manage accountparameters of one or more children associated with the parent orguardian. For example, the parent or guardian can set limits on thenumber of payment requests that a child may make during a predeterminedperiod of time (e.g., over a period of a week, month, or year), themonetary amount associated that a child may request on a “per request”and/or over a specified period of time.

In order to manage the children's account parameters and/or the parent'saccount information, the parent must first log on to the related partypayor system in order to access the parent's account (step 800). Oncethe parent has logged onto the system, the parent may then update theparent's contact information (step 802). For example, the parent mayupdate a contact email address or mobile phone number at which theparent may be notified if a new payment request and/or message isreceived from a child. The parent may also update the payment sourceinformation that the system may use when processing a payment for apayment request that has been authorized by the parent (step 804). Forexample, the parent may add a new credit or debit card account that maybe used as a payment source when processing payments.

The parent may also select a child (a requestor) from the list ofchildren associated with the parent or guardian (step 805) whose accountsettings are to be modified. In some embodiments, a parent may only havea single child associated with the parent's account, while in otherembodiments a parent may have multiple children associated with theparent or guardian. According to one embodiment, the user interfacemodule 210 may provide a user interface that includes a list of childrenassociated with the parent's account and the parent may select a childfrom the list. According to another embodiment, the user interfacemodule 210 may provide a tabbed user interface where information relatedto each child associated with a parent account is displayed on aseparate tab that is selectable by the parent.

After selecting a child whose account settings are to be modified, theparent may set limits on the monetary amounts that a child can request(step 810). In one embodiment, the user interface module 210 generates achild account maintenance user interface that allows the parent to entera maximum monetary amount per request that the child may request (e.g.,each payment request may be for no more than $50). The parent can alsoset limits on the maximum amount of money that child can request overallwithin a predefined period of time (e.g., the child cannot request morethan $200 during a month and no more than $1000 during a year).

The parent may also set limits on the number of request that a child maymake within a predefined period of time (e.g., no more than two requestsper week and no more than four requests per month) (step 815). Theparent may also set limits on the number of payment requests that achild may sent to some or all of the payors. For example, the parent maylimit the number of payment requests that may be sent to the child'sgrandparents to one per month, while limiting the number of requeststhat the child may send to the parent or guardian to five per month.

The parent may also designate approved contributors or third partypayors to which the child may send payment requests (step 820). In anembodiment, the parents or guardian may designate a group of approvedpeople or contributors to whom the child may send requests for payment.

The parent may also view the transaction history for the child (step825). The transaction history for the child can include all of the thirdparty payment requests submitted by the child over a predeterminedperiod of time. The status of each of the payment requests can also bedisplayed so that the parent can see which payment requests have beendenied, which payment requests have been approved, and which third partypayments requests are still pending.

Those of skill will appreciate that the various illustrative logicalblocks, modules, and algorithm steps described in connection with theembodiments disclosed herein can often be implemented as electronichardware, computer software, or combinations of both. To clearlyillustrate this interchangeability of hardware and software, variousillustrative components, blocks, modules, and steps have been describedabove generally in terms of their functionality. Whether suchfunctionality is implemented as hardware or software depends upon theparticular system and design constraints imposed on the overall system.Skilled persons can implement the described functionality in varyingways for each particular system, but such implementation decisionsshould not be interpreted as causing a departure from the scope of theinvention. In addition, the grouping of functions within a module, blockor step is for ease of description. Specific functions or steps can bemoved from one module or block without departing from the invention.

The various illustrative logical blocks and modules described inconnection with the embodiments disclosed herein can be implemented orperformed with a general purpose processor, a digital signal processor(DSP), a text messaging system specific integrated circuit (ASIC), afield programmable gate array (FPGA) or other programmable hardwaredevice, discrete gate or transistor logic, discrete hardware components,or any combination thereof designed to perform the functions describedherein. A general-purpose processor can be a microprocessor, but in thealternative, the processor can be any hardware other processor,controller, or microcontroller. A processor can also be implemented as acombination of computing devices, for example, a combination of a DSPand a microprocessor, a plurality of microprocessors, one or moremicroprocessors in conjunction with a DSP core, or any other suchconfiguration.

The steps of a method or algorithm described in connection with theembodiments disclosed herein can be embodied directly in hardware, in asoftware module executed by a processor, or in a combination of the two.A software module can reside in computer/processor readable oraccessible storage such as RAM memory, flash memory, ROM memory, EPROMmemory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM,or any other form of storage medium. An exemplary storage medium can becoupled to the processor such that the processor can read informationfrom, and write information to, the storage medium. In the alternative,the storage medium can be integral to the processor. The processor andthe storage medium can reside in an ASIC.

The above description of the disclosed embodiments is provided to enableany person skilled in the art to make or use the invention. Variousmodifications to these embodiments will be readily apparent to thoseskilled in the art, and the generic principles described herein can beapplied to other embodiments without departing from the spirit or scopeof the invention. Thus, it is to be understood that the description anddrawings presented herein represent a presently preferred embodiment ofthe invention and are therefore representative of the subject matter,which is broadly contemplated by the present invention. It is furtherunderstood that the scope of the present invention fully encompassesother embodiments that may become obvious to those skilled in the art.

We claim:
 1. A computer-implemented method for processing a paymentrequest with a related party payment, where one or more processors areprogrammed to perform steps comprising: holding a balance of funds in anescrow account for a user, the balance of funds being supplied by afirst funding source and a subsequent funding source; receiving anelectronic payment request at the one or more processors from a vendorfor the purchase of an item selected by the user; sending the paymentrequest at the one or more processors for the purchase of the itemselected by the user; funding a payment to the vendor from the escrowaccount; and maintaining a transaction history accessible to the userthrough a user account and to a supervisor of the user through asupervisory account.
 2. The computer-implemented method of claim 1,wherein the first funding source is associated with the supervisoryaccount.
 3. The computer-implemented method of claim 2, wherein thesubsequent funding source is associated with a contributor account andthe contributor account is authorized by the supervisor to supply fundsto the escrow account.
 4. The computer-implemented method of claim 2,wherein the subsequent funding source is associated with the supervisoryaccount.
 5. The computer-implemented method of claim 1, wherein thesupervisor is a parent of the user.
 6. The computer-implemented methodof claim 1, further comprising: sending a payment authorization requestto the supervisor and receiving an authorization approval from thesupervisor prior to funding the payment to the vendor from the escrowaccount.
 7. A system for processing payment requests for a superviseduser, the system comprising: a computer readable storage device forstoring computer executable programming modules; a processorcommunicatively coupled with a computer readable storage device forexecuting programmed modules stored therein; a payment processing moduleconfigured to process payment transactions from an escrow accountincluding funds supplied by a first funding source and a subsequentfunding source using third party payment processors including processingnetworks for credit cards; and an account manager module configured tocreate a user account for a first person, the user account havingassociated therewith a set of permissions, create a supervisory accountfor a supervisory contributor, the supervisory account having theability to set the permissions associated with the user account and theability to view a transaction history of the user account, wherein thefirst funding source is associated with the supervisory account, andcreate a contributor account for a second contributor, the secondcontributor account being associated with the second funding source. 8.The system of claim 7, wherein the supervisory account imposeslimitations on the second contributor.
 9. The system of claim 7, whereinthe supervisory contributor is a guardian of the user.
 10. The system ofclaim 7, wherein the account manager module is configured to create asecond user account for a second person, the second user account havingassociated therewith a second set of permissions, and wherein thesupervisory account has the ability to set the second permissionsassociated with the second user account and the ability to view a secondtransaction history of the second user account.
 11. The system of claim7, wherein the supervisory account is configured to approve transactionpayments.
 12. A computer-implemented method for processing a paymentrequest with a related party payment service, where one or moreprocessors are programmed to perform steps comprising: holding a balanceof funds in an escrow account for a user, the balance of funds beingsupplied by a supervisory contributor and a second contributor, whereinthe second contributor is authorized by the supervisory contributor tosupply funds to the escrow account; receiving an electronic paymentrequest at the one or more processors from a vendor for a purchase of anitem selected by the user; processing the payment request at the one ormore processors for the purchase of the item selected by the user;funding a payment to the vendor from the escrow account for the user;and maintaining a transaction history accessible to the user and to thesupervisory contributor.
 13. The system of claim 12, wherein thesupervisory contributor imposes limitations on the second contributor.14. The system of claim 12, wherein the supervisory contributor providesfunds from a first funding source.
 15. The system of claim 14, whereinthe second contributor provides funds from a second funding source. 16.The system of claim 14, wherein the supervisory contributor providesfunds from a second funding source.
 17. The system of claim 12, furthercomprising: sending a payment authorization request to the supervisorycontributor and receiving an authorization approval from the supervisorycontributor prior to funding the payment to the vendor from the escrowaccount.
 18. The system of claim 12, wherein the supervisory contributoris a guardian of the user.
 19. The system of claim 17, wherein thesecond contributor is a second guardian of the user.